The invention relates to a method for locating and scheduling access to "servers" in a distributed computing environment. More specifically, the invention relates to a method for locating and scheduling access to servers that operate in the OSF distributed computing environment commonly referred to as "DCE." The invention is particularly useful with respect to access to a single-thread DCE server process by a context-sensitive client process.
The discussion below refers at several points to a useful reference work by three employees of the assignee of this application, "Understanding DCE," by Ward Rosenberry, David Kenney, and Gerry Fisher (Sebastopol, Calif.: O'Reilly & Associates, Inc., 1992), hereinafter referred to as [RKF], which is incorporated by reference as background information well-known to those of ordinary skill.
1.1 Clients, Servers, and Interfaces, and RPCs in a DCE Environment
In the OSF DCE environment, service requests may be transmitted as "remote procedure calls" (RPCs) that conform to a standard specification. RPCs permit standardized communication among nonidentical and even nonstandard components in a DCE network.
A special category of program instructions in the DCE environment is referred to as "stub code." Generally speaking, stub code comprises standard program instructions that act as a communications interface between a main program (either a client program or a server program) and one or more remote processes. See generally [RKF] sections 3.1.2 and 3.5.
(Those of ordinary skill having the benefit of this disclosure will of course recognize that descriptions of program code performing a particular function, e.g., stub code "acting" as a communications interface, are in fact convenient and conventional shorthand references to the operation of one or more processors executing instructions comprising the program code.)
The term "server" is commonly used to refer to a computer program, executing on an appropriate processor system ("server host"), that carries out service requests made by, e.g., other computer programs that may be executing on the same or other computer systems. In most implementations a server executes on a specified computer and receives service requests from other computers over a communications network. See generally [RKF] at section 1.2.
More specifically, an RPC "server" is commonly defined as a "process" that "exports" one or more "interfaces" capable of being invoked by remote clients. A "process" refers generally to the execution by a physical processor (or processor system) of one or more series of instructions in a specified "address space,", i.e., a system environment that includes particular physical resource allocations, open files, static data, etc.
The term "interface" in the DCE environment refers generally to a formal specification of inputs and outputs for a specified service, wherein a service request that complies with the input specification results in a server process acting to generate output that complies with the output specification. The term "export an interface" generally refers to the transmittal by a server process of pre-formatted information containing interface and binding specifications to a namespace server for recordation in a "namespace" server data structure." See generally [RKF] section 9.3.
Generally speaking, a client process that desires to invoke a server interface sends a request (e.g., an RPC) to the namespace server requesting a "binding handle" for the server in question that implicitly encodes the network address of the server; the client may subsequently use the binding handle in a single RPC to request that services be performed by the server. The client may indicate via an RPC argument that the server's services are desired over a series of RPCs in connection with a "transaction," i.e., a series of related service requests. In such a situation the server maintains the "context," the system state, and the binding handle remains valid, until the client indicates (again via an RPC argument) that the transaction is complete.
Thus, a server that exports an interface in effect is announcing (to "client" processes that are designed using a priori knowledge of the interface) that the specified kinds of outputs can be obtained from the server process. See generally [RKF] section 3.3.
In some implementations a single copy of the namespace server may be maintained, with all server access requests being processed at that copy. In larger implementations with a high number of network nodes, it might be more efficient to maintain a copy of the namespace server at several nodes or even at each node, with periodic internode communications for updating purposes. In either case, a node on which a copy of the namespace server is maintained is referred to herein as a namespace server.
1.2 Multi-Threaded Servers
The DCE environment permits a wide variety of computer systems and subsystems to be "connected" together for mutual sharing of resources. Some systems may be capable of multi-thread operation, while others may be capable only of single-thread operation.
(As is well-known to those of ordinary skill, generally speaking a "thread" is a sequence of computer instructions. A given process may have multi-thread capability. That is, the operating system supporting the process may be designed so that the physical processor system rotates its actual processing activity among several different series of program instructions, or "threads," in a specified sequence, or possibly in accordance with a priority scheme, with all threads using the same address space.)
The OSF DCE specification assumes all servers to be multi-thread in nature and thus able to handle multiple concurrent calls. A multi-thread DCE server comprises a single process capable of executing multiple threads by sharing the process's address space among its threads using mutexes (mutual exclusion locks) or global locks. Such mechanisms are used to protect portions of memory that must remain constant while a particular thread "waits" for the processor's attention (i.e. while the processor is executing instructions from another thread). When a service request or "call" is received by a multi-thread server, a specific thread (referred to as a "call executor" thread) is allocated to handle the call. As each thread completes its processing of a call, it becomes available for assignment to another call. See generally [RKF] chapter 4.
A single-thread process intended as a would-be server, on the other hand, would be able to handle only one request for service at a time. Service requests would necessarily be executed serially instead of concurrently. (Single-thread processes are sometimes referred to as "non-reentrant" because they cannot share an address space among independent service requests.)
1.3 Backward Compatibility Problems of Single-Thread Servers
Single-thread servers present a fundamental problem in the DCE environment because the design of the DCE assumes that any necessary scheduling of server resources for handling service requests is handled locally at each server. As noted above, the DCE protocol is designed to permit the sending of multiple concurrent requests to a single server. See generally [RKF] section 4.2. The lack of backward compatibility with existing single-thread application programs that cannot be used as DCE servers thus presents a significant "chicken and egg" barrier to the growth of DCE computing. Specifically, the present size of the DCE installed base might not justify the cost and difficulty of creating thread-compliant implementations from non-reentrant software. Many existing computer systems operate environments where single-threaded (and therefore non-reentrant) server-type software is assumed. Vendors of such "legacy" software often are economically forced to allocate resources to servicing their own installed base of non-reentrant products. It follows that for such vendors, conversion to thread compliance might not be a priority until the DCE installed base expands. Such expansion might not occur, however, until the availability of software expands.
1.4 Prior Attempts to Accommodate Single-Thread Servers in the DCE
To some extent, the creators of the DCE environment anticipated backward compatibility problems. As a result, a limited workaround was designed into the standard DCE software. The basis of the solution is the availability of a "global lock." Under this scheme, if a thread must execute non-reentrant code then it must first acquire the global lock. Once a thread has acquired a global lock it can execute to completion, secure in the knowledge that no other thread will execute simultaneously utilizing the resources controlled by the global lock. Because client processes can rarely be certain that service requests will not involve non-reentrant code, nearly all requests will indeed involve obtaining the global lock. Operation in such a mode can essentially paralyze the client processor system (especially in the event of a "hangup" in a thread that has the global lock) and eliminate the benefits of multi-thread computing.
A variation on the global lock solution is the "jacket routine," which represents a refinement of the basic global lock concept with respect to certain commonly used, non-reentrant, UNIX system calls. In order to enable the use of these system calls, DCE Threads (an implementation of threads standard in the DCE), provides a jacket routine. Instead of making a UNIX system call, threads call the corresponding jacket routine. The jacket routine acquires the global lock, runs, then releases the global lock. See generally [RKF] section 4.2. The use of jacket routines can cause the same problem as the use of global locks.
Two other potential solutions are proposed in a memorandum dated Sep. 4, 1992, privately distributed by Tandem Computer Corporation, a copy of which is being filed with an information disclosure statement in conjunction with this application. The first proposed approach assumes the use of single-thread DCE servers in conjunction with a "monitor process" that directs the clients to bind and rebind with the appropriate server. Specifically, the client: 1) issues an RPC to the monitor asking for a binding for an idle server; 2) uses the binding to issue at least one RPC to the server; and 3) issues an RPC call to the monitor to release the server. The advantage of this approach is that the server can only be accessed by one client at a time and that the client can access servers on more than one host. A disadvantage to this approach is performance, because it requires RPC calls every time a server is selected.
The Tandem memorandum recognizes that some problems would exist with this approach. First, once a server is allocated to a particular client process, it is unavailable to other clients until the particular client issues a release RPC to the monitor. That allows the client to make several RPC calls while in possession of the server. Because the client may wait an arbitrary length of time between calls (subject to any system timeout constraints), the server may sit idle for significant periods of time. Furthermore, runtime threads may be blocked resulting in network problems. Second, the allocate and release calls increase network traffic. Third and perhaps most significantly, the setup overhead (for establishing a connection) is repeated every time a client switches from one server to another.
The second approach proposed in the Tandem memorandum seeks to solve the problem by enhancing the server's duties and subdividing it into two process types: 1) a "server master process" that would act as the communication endpoint and the place where RPC runtime state is maintained; and 2) an "agent process" that would run the application manager code. The agent process thus would serve as an extension of a call executer thread of the server master process, with one agent process assigned to each client request. This division of function would allow the server's stub code and its manager function to run in separate processes thereby eliminating scheduling and protection problems.
A possible disadvantage of the agent-process approach would be the overhead associated with two context switches per RPC. Moreover, it might be necessary for the server master-process program to be designed with knowledge of every agent-process program, which could be an administrative burden especially in terms of keeping the server master-process program up to date.